PvXwiki:True Build Ratings
* This policy would compliment and work in unison with many of the proposed policies available to replace the PvXwiki:Build vetting procedure. This policy is here to adress how we rate builds with solutions to many of the complaints people voiced about the old system. It is focused primarily at how we rate builds, and not how we select favored/unfavored classifications, revotes, or deletion candidates. But it does contain many tools that may help in the clarification of those other policies. Build ratings for testing * This is a suggested solution to help encourage testing and actual, rational thinking about the builds submitted for approval. If put in place it would slowdown the *Glance and Unfavor* and possibly mitigate the *Flavor of the Month* builds that don't particulary work very well. * Initial voting is to make this policy optional, and put the policy into a 3 month testing patern after it is established. After testing, voting on whether or not to keep the system as an official policy would then occur. Everyone seems to be having difficulty with yes/no concept of build vetting. Some people claim that build voting is pure abstract opinion, yet people can look at a build and instantly tell if is good or bad. Builds are not works of art, they are mechanical systems designed to do specific things, and as such can be rated in accordance with what it's designed to do. This could be best done by giving the build attributes using a numerical value, from 1-10, that are voted on by the community. There would be single core attributes category along with subtype categories that would be augmented by additional sub attributes to meet the builds capability. This would garnish a true evaluation of the build and its abilities, and help mitigate the 'glance and favor/unfavor' people as they would be forced to think about the build. Non-testers could be more easily screened out at that point. * Each build would recieve the standard "Favored" or "Un-Favored" vote. * In addition Each build would be rated with the selected region or arena in mind. :An idea for the core attributes to a build would be: :* Overall :* Energy/Adrenal Management, :* Survivability :* Micromanagement (Ease of use) :* Vulnerability :* Adaptability :* Sustainment :Each subtype is based on the general concept of what the build is supposed to do. : For example: Healer/Prot Monk :* Hex Removal :* Condition Removal :* Damage Prevention :* Spike Counter :* Healing :* Utility Additional sub attributes could be added to showcase any 'oddball' aspects the build was designed to accomplish. Such as a SoMW spike monk would also receive: :* Damage Output :* Spike Ability Rating descriptions would need to be created for each attribute, and the number of attributes and template types kept to as few as possible, with oddball builds simply given an additional attribute field to match it's ability. The most important attribute to look, other than the 'Favored/Un-Favored' vote: would be the "Overall" attribute. This denotes the builds usefulness in the designed area in which it is to work. So a build could potential have a high Overall score but low sub attribute scores if it worked very well in the designed circumstance or is part of a team concept. ::An example of the numerical values of the Overall Category would look something like this: :*1 - The build is completely ridiculous and does not work at all (such as a build that tries to utilize skills from seven different attributes). :*2 - The build is simply broken or lacks an elite (most noob or beginner builds people try to make). :*3 - The build is functional but makes poor skill selections and is very difficult to use (like an Ether Lord e-denial build). :*4 - The build is functional, but only in very specific situations and is not reliable (such as a Pacifism monk). :*5 - The build works, but there are much better examples of its type already out there (such as the default Zealous Benediction monk suggested by the primer articles). :*6 - The build works well, but is hurting in a minor area such as condition removal or e-management (such as a Fast Casting monk). :*7 - This build is solid and would be a good example of it's type (such as the RC/Prot monk for Hero's Ascent). :*8 - This build works very well and can even accomplish a few things that aren't in its design scope (such as the A/Me Solo Sin). :*9 - A prime example of what a build of this type should be (such as a stanced LoD Infuser). :*10 - The Uber l33t version of the build. Will incite a massive nerfing backlash by Anet! (Such as boon prot, back in the day when it worked.) Anything a that an admin sees as receiving a 5 or less is immediately available to be Deleted as in accordance with PX:Well. -The community could figure out what kind of attributes need to be related to each kind of build and then each person, when they vote, put the rating of the build further down on the page. A script would then tally the marks in a table at the top of the page (near the votes) to allow for better understanding of the strength's and weaknesses of the build. I know this would be a lot of crazy work, but it might be a really cool feature to have and fix a lot of problems we experience with the vetting system. Concept for scripting I am not a coder, but here is the idea how to do it. * For ease of use, this would require a few 'web forms' to be created with appropriate scripting, to ensure that everything is easy to use and uniform. * The first form is used to create the initial 'Totals' template at the top of a page. When a build is ready to go into the 'untested' phase after being built, the author (or admin) goes to our 'Create Rating Template' page. Here will be an explination that the core attributes will be included on all build rating, then they select a sub type, which will give that build an attribute set specific to a pre-established association with that type. Then the builder is able to hit bubble boxes to select any additional attributes needed to adress specific unique aspects to that build. A template code will be generated and will be available to be copy and pasted to the discussion page. * The template code shows up on the discussion page as a table with appropriate attribute headings and '-' in their numbers slot for unrated builds, it also has a link to a 'temporary' page Titled "Voting - Build: XXXX" that will generate a voting form based on the template at the top of the discussion page. This page would best be opened in a 'new tab' or 'new page' to allow the user to quickly return to the discussion page. * That form will contain all the attributes associated with that build, and will also have two additional fields, "Favored/Unfavored" (Yes/No) and a quick comment area for a 25-50 character remark. When hoving your mouse over a bubble for a particular attribute, the user would recieve a pop-up (similar to skill description pop-up) detailing what this number in this attribute equates to, as a friendly reminder and to help users truly evaluate builds. After making their selections, the template code will be rendered and available to be copied and pasted to the associated voting page in the appropriate voting area. The quick comments field will help contain lengthy arguments that tend to arise inapropriately under the votes - to the discussion portion of the page. * On the voting page you will then see the table expand to include 'favored' and 'unfavored' votes, with the user's name and quick comment. At the top is only the averages of the sugested build (So as not to clutter the page). At the bottom of the page the entire voting template will simply show up like: " Shireen Has voted on date ". This will help to ensure that the actual voting areas remains clean an organized. * An additional link to a 'temporary' page on each template could also be created to see the breakdown and user contribution votes. * This kind of system would force voting uniformity, keep the pages clean-er and more user friendly. Plus voting would be handled through a quick matter of "Bubble, Bubble, Bubble" - Copy and paste. * I will not attempt to specify at what point a build should be considered favored or unfavored, as that is something still best left to the admins. If an admin feels that a favored/unfavored policy should be tacked onto this policy, please feel free to do so. * To help with re-votes or skill updates the table could be told only to look for votes placed in certain sub-sections of the build discussion page. Example of Voting To give a visual refrence, I am going to take one of my favorite builds that was unfavored back on Guildwiki as a safe example of what this could look like. This is not meant for approval/disaproval of the build itself. The Build Page (condensed) prof=mesme/monk fastca=12+1+2 inspir=2 protec=12 healin=2benedictionof fortuneconditionguardianhandshexhexchant/build Gear would be FC/FR Wand and focus for prot. 500 health, 50 energy. (moot point) This build is meant to be used in RA, with it's Fast Casting and hex removal this is a difficult monk to shut down. This would be on the discussion page :Votes Favored: 1 - Votes Unfavored: 0 : Attributes: would appear when mouse is put over attribute or number, with an explination of what they mean :| Core Attribs: | Monk Atribs | Additional | Create your vote (link) :| OvA | EAM | Sur | MiM | Vul | Adp | Sus | HxR | CdR | DaP | SpC | Hea | Utl | | Show Breakdown of votes (link) :| 4 | 7 | 6 | 3 | 7 | 6 | 5 | 8 | 6 | 5 | 7 | 5 | 5 | | : = Rate-a-build -FC RA Monk (This would be an extension of the table above) Please test and vote on new builds. Testing is encouraged but not required. Favored: #''It works but is difficult to use'' -Shireen Unfavored: #''No votes recieved'' : And then down at the bottom of the page all you would see is -= Voting section (Place your voting template codes here) = * Shireen has voted on November 11, 1775. -=- The abbrivations translated - In the finished product you could do hover overs... : Ova = Overall : EAM = Energy/Adrenal Management, : Sur = Survivability : MiM = Micromanagement (Ease of use) (Recieved a low score due to the dificulty of use) : Vul = Vulnerability (Recieved a 7 for being difficult to shut down using standard anti-caster tactics) : Adp = Adaptability : Sus = Sustainment : HxR = Hex Removal : CdR = Condition Removal : DaP = Damage Prevention : SpC = Spike Counter : Hea = Healing : Utl = Utility